Blockchain-based transaction method and apparatus, and remitter device

ABSTRACT

Implementations of the present specification provide a blockchain-based transaction method and apparatus, and a remitter device. The method includes: calculating a transaction amount commitment, a first commitment random number ciphertext, and a second commitment random number ciphertext; and submitting transaction data to the blockchain, the transaction data including the transaction amount commitment, the first commitment random number ciphertext, and the second commitment random number ciphertext, for the transaction amount commitment and the first commitment random number ciphertext to be recorded into a remitter account, and the transaction amount commitment and the second commitment random number ciphertext to be recorded into a remittee account.

TECHNICAL FIELD

Implementations of the present specification relate to the field ofcomputer technologies, and particularly, to a blockchain-basedtransaction method and apparatus, and a remitter device.

BACKGROUND

The blockchain technology is a distributed database technology thatprotects data from being tampered with and forged by using cryptographyand consensus mechanisms. With the development of computer and Internettechnologies, thanks to advantages such as decentralization, opennessand transparency, tamper-resistance, and trustiness, the blockchaintechnology is highly favored and is widely applied to many fields suchas smart contracts, securities transactions, E-commerce, the Internet ofThings, social communication, file storage, proof of existence, identityverification, and equity crowdfunding.

Currently, when the blockchain technology is applied to transactionscenarios, because transaction information needs to be sent to theblockchain for verification, implementation, and chaining-on, thetransaction information is at risk of being leaked to a third partyunrelated to the transaction.

There is a need of a technical solution for realizing privacy protectionin a transaction process.

SUMMARY

The implementations of the present specification provide ablockchain-based transaction method and apparatus, and a remitterdevice, to achieve, among others, privacy protection without interactionwith a remittee device.

An implementation of the present specification provides ablockchain-based transaction method, including: calculating atransaction amount commitment based on a commitment random number and atransaction amount; obtaining a first commitment random numberciphertext by encrypting the commitment random number based on ahomomorphic encryption public key of a remitter account and thetransaction amount using a homomorphic encryption algorithm; obtaining asecond commitment random number ciphertext by encrypting the commitmentrandom number based on a homomorphic encryption public key of a remitteeaccount and the transaction amount using the homomorphic encryptionalgorithm; and submitting transaction data to the blockchain, thetransaction data including the transaction amount commitment, the firstcommitment random number ciphertext, and the second commitment randomnumber ciphertext, for the transaction amount commitment and the firstcommitment random number ciphertext to be recorded into the remitteraccount, and the transaction amount commitment and the second commitmentrandom number ciphertext to be recorded into the remittee account.

An implementation of the present specification provides ablockchain-based transaction apparatus, including: a calculation unit,configured to calculate a transaction amount commitment based on acommitment random number and a transaction amount; a first encryptionunit, configured to obtain a first commitment random number ciphertextby encrypting the commitment random number based on a homomorphicencryption public key of a remitter account and the transaction amountusing a homomorphic encryption algorithm; a second encryption unit,configured to obtain a second commitment random number ciphertext byencrypting the commitment random number based on a homomorphicencryption public key of a remittee account and the transaction amountusing the homomorphic encryption algorithm; and a submission unit,configured to submit transaction data to the blockchain, the transactiondata including the transaction amount commitment, the first commitmentrandom number ciphertext, and the second commitment random numberciphertext, for the transaction amount commitment and the firstcommitment random number ciphertext to be recorded into the remitteraccount, and the transaction amount commitment and the second commitmentrandom number ciphertext to be recorded into the remittee account.

An implementation of the present specification further provides aremitter device, including: a memory, configured to store computerinstructions; and a processor, configured to execute the computerinstructions to implement the method described in any of theimplementations of the present specification.

It can be understood from the technical solutions provided in theimplementations of the present specification, in the implementations ofthe present specification, the transaction amount commitment, the firstcommitment random number ciphertext, and the second commitment randomnumber ciphertext can be obtained by using the commitment mechanism andthe homomorphic encryption mechanism. The transaction amount commitment,the first commitment random number ciphertext, and the second commitmentrandom number ciphertext can be submitted to the blockchain, for thetransaction amount commitment and the first commitment random numberciphertext to be recorded into the remitter account, and the transactionamount commitment and the second commitment random number ciphertext tobe recorded into the remittee account. On the one hand, privacyprotection can be realized for transaction information such as thetransaction amount by using the commitment mechanism and the homomorphicencryption mechanism. On the other hand, the transaction can be smoothlycompleted in the blockchain without the remittee device by submittingthe transaction amount commitment, the first commitment random numberciphertext, and the second commitment random number ciphertext to theblockchain. Therefore, the implementation can realize privacy protectionunder a non-interactive condition.

BRIEF DESCRIPTION OF DRAWINGS

To describe the technical solutions in the implementations of thepresent specification or in the existing technology more clearly, thefollowing outlines the accompanying drawings for illustrating suchtechnical solutions. Clearly, the accompanying drawings outlined beloware some implementations of the present specification and a personskilled in the art can derive other drawings from such accompanyingdrawings without creative efforts.

FIG. 1 is a schematic diagram illustrating blockchain-based transactionimplementation according to an implementation of the presentspecification;

FIG. 2 is a flowchart illustrating a blockchain-based transaction methodaccording to an implementation of the present specification;

FIG. 3 is a flowchart illustrating blockchain-based transactionimplementation according to an implementation of the presentspecification;

FIG. 4 is a function structural diagram illustrating a blockchain-basedtransaction apparatus according to an implementation of the presentspecification; and

FIG. 5 is a function structural diagram illustrating a remitter deviceaccording to an implementation of the present specification;

FIG. 6 is a diagram illustrating example environments that can be usedto execute embodiments of this specification; and

FIG. 7 is a diagram illustrating an example architecture in accordancewith embodiments of this specification.

DESCRIPTION OF IMPLEMENTATIONS

The descriptions herein clearly and comprehensively describe thetechnical solutions in the implementations of the present specificationwith reference to the accompanying drawings in the implementations ofthe present specification. Clearly, the described implementations aremerely some example implementations rather than all of theimplementations of the present specification. All other implementationsobtained by a person of ordinary skill in the art based on theimplementations of the present specification without creative effortsshall fall within the protection scope of the present specification.

Referring to FIG. 1 and FIG. 2, an implementation of the presentspecification provides a blockchain-based transaction method.

In this implementation, the blockchain can be a distributed ledger thatorganizes multiple pieces of block data in a chain structure based on atime sequence, and ensures security, traceability, and tamper-resistanceby using a cryptography algorithm. The blockchain can include a publicblockchain, a consortium blockchain, a private blockchain, etc. Theblockchain can be implemented based on a blockchain network. Theblockchain network can include a peer-to-peer network (P2P network),etc. The blockchain network can include a plurality of blockchain nodes.Unified blockchain ledgers are maintained among blockchain nodestogether, with copies of the blockchain ledger stored, respectively, oneach of at least some of the plurality of nodes of the blockchainnetwork.

In the implementations, the transaction method can be executed by aremitter device. The remitter device can join the blockchain network asa blockchain node. A remitter account can be logged into on the remitterdevice. The remitter account can be an account of a remitter in theblockchain. The remitter account can have a signature public-private keypair, and an encryption public-private key pair. The signaturepublic-private key pair can include a signature public key and asignature private key that are associated. The signature private key canbe used to sign transaction data to be submitted to the blockchain. Thesignature public key can be disclosed to other blockchain nodes in theblockchain network for the other blockchain nodes to verify the signedtransaction data. The encryption public-private key pair can include ahomomorphic encryption public key and a homomorphic encryption privatekey that are associated to one another. The homomorphic encryptionpublic key can be disclosed to other blockchain nodes in the blockchainnetwork, so the other blockchain nodes can encrypt data, e.g., aremitter balance, a remitter random number, and a commitment randomnumber, by using a homomorphic encryption algorithm. The homomorphicencryption private key can be used to decrypt an encrypted ciphertext.The remitter account can also register a remitter balance commitment anda remitter random number ciphertext in the blockchain.

The remitter balance commitment can be calculated by the remitter devicebased on the remitter random number and the remitter balance. Theremitter random number can be a random number corresponding to theremitter account and used for constructing the remitter balancecommitment. The remitter balance can be a balance of any type ofresource. The resource can include, for example, securities, coupons,property, virtual currency, and funds. Specifically, the remitterbalance commitment can be implemented based on any type of commitmentscheme with homomorphism, such as a Pedersen commitment mechanism.Taking the Pedersen commitment mechanism as an example, the remitterbalance commitment can be calculated based on equationPC(r_A,s_A)=g^(r_A)h^(s_A), where, PC(r_A,s_A) is the remitter balancecommitment; r_A is the remitter random number; s_A is the remitterbalance; g and h are pre-determined parameters, respectively. Certainly,the remitter balance commitment can also be implemented by using ahomomorphic encryption algorithm. That is, a ciphertext obtained byencrypting the remitter balance based on the homomorphic encryptionalgorithm is used as the remitter balance commitment. The homomorphicencryption algorithm will be described in detail subsequently. As such,on the one hand, direct registration of the remitter balance can beavoided by registering the remitter balance commitment in theblockchain, so the remitter balance can be hidden and kept secret. Onthe other hand, because the commitment mechanism can support ahigh-efficiency zero-knowledge proof, the remitter balance commitmentcan make a zero-knowledge proof, e.g., a third zero-knowledge proof inthe subsequent process, process involving the remitter balance in thesubsequent process more efficient.

The remitter random number ciphertext can be obtained by encrypting theremitter random number based on the remitter balance by using thehomomorphic encryption algorithm. Specifically, the remitter device canobtain the remitter random number ciphertext by encrypting the remitterrandom number based on the homomorphic encryption public key of theremitter account and the remitter balance using the homomorphicencryption algorithm. The homomorphic encryption algorithm can include,for example, the Okamoto-Uchiyama algorithm and the Boneh-Goh-Nissimalgorithm. Taking the Okamoto-Uchiyama algorithm as an example, theremitter random number ciphertext can be calculated based on equationOU_A(r_A)=u1^(r_A)v1^(s_A), where OU_A(r_A) is the remitter randomnumber ciphertext; r_A is the remitter random number; each of u1 and v1is a portion of the homomorphic encryption public key of the remitteraccount; s_A is the remitter balance. In the implementations, theremitter random number can be used as an encrypted plaintext, and theremitter balance can be used as a random number for homomorphicencryption, thereby enabling encryption of the remitter random number.On the one hand, the burden caused by locally keeping the remitterrandom number off the chain can be avoided by registering the remitterrandom number in the blockchain. On the other hand, direct registrationof the remitter random number can be avoided by registering the remitterrandom number ciphertext in the blockchain, so the remitter randomnumber can be hidden and kept secret.

It should be noted that, when it is necessary to obtain the remitterbalance, the remitter device can obtain the remitter random number bydecrypting the remitter random number ciphertext using a homomorphicencryption private key of the remitter account; and can calculate theremitter balance based on the remitter random number and the remitterbalance commitment. The remitter device can calculate the remitterbalance by using, for example, the Kangaroo method in the Pollardalgorithm. Certainly, the Kangaroo method listed herein is merely anexample, and in practice the remitter device can calculate the remitterbalance in other ways. For example, the remitter random numberciphertext can be OU_A(r_A)=u1^(r_A)v1^(s_A), and the remitter balancecommitment can be PC(r_A,s_A)=g^(r_A)h^(s_A). Then, the remitter devicecan obtain the remitter random number r_A by decrypting the remitterrandom number ciphertext OU_A(r_A) using the homomorphic encryptionprivate key of the remitter account; calculate h^(s_A) based on theremitter random number r_A and the remitter balance commitmentPC(r_A,s_A); and calculate the remitter balance s_A based on h^(s_A) byusing the Kangaroo method in the Pollard algorithm. In addition, whenthe remitter balance commitment is implemented by using the homomorphicencryption algorithm, the remitter device can obtain the remitterbalance by decrypting the remitter balance commitment using thehomomorphic encryption private key of the remitter account.Specifically, for example, the remitter balance commitment implementedby using the Okamoto-Uchiyama algorithm can bePC(r_A,s_A)=u1^(s_A)v1^(r_A).

In the implementations, the transaction method can transfer thetransaction amount from the remitter account to a remittee account. Theremittee account can be an account of a remittee in the blockchain. Theremittee account can be logged into on a remittee device. The remitteedevice can join the blockchain network as a blockchain node. Thetransaction amount can be negotiated between the remitter and theremittee. Similar to the remitter account, the remittee account can havea signature public-private key pair, and an encryption public-privatekey pair. The remittee account can also register a remittee balancecommitment and a remittee random number ciphertext in the blockchain.The remittee balance commitment can be calculated by the remittee devicebased on the remittee random number and the remittee balance. Theremittee random number ciphertext can be obtained by encrypting theremittee random number based on the remittee balance by using thehomomorphic encryption algorithm.

The transaction method can include the following steps. It should benoted that although the present specification provides the methodoperation steps in the implementations or the flowcharts, more or feweroperation steps can be included based on conventional or non-creativeefforts. In addition, a sequence of the steps listed in theimplementation is merely one of numerous execution sequences of thesteps, and does not represent a unique execution sequence. In actualexecution of an apparatus or a product, execution can be performed basedon the method sequence shown in the implementation or the accompanyingdrawing, or performed in parallel, e.g., a parallel processor or amulti-thread processing environment.

Step S10: Calculate a transaction amount commitment based on acommitment random number and a transaction amount.

In the implementations, the commitment random number can be generated bythe remitter device. The transaction amount can be negotiated betweenthe remitter and the remittee. The transaction amount commitment can beimplemented based on any type of commitment scheme with homomorphism,such as a Pedersen commitment mechanism. Taking the Pedersen commitmentmechanism as an example, the transaction amount commitment can becalculated based on equation PC(r,t)=g^(r)h^(t), where, PC(r,t) is thetransaction amount commitment; r is the commitment random number; t isthe transaction amount; g and h are pre-determined parameters,respectively. As such, the transaction amount can be hidden and keptsecret by using the transaction amount commitment.

Step S12: Obtain a first commitment random number ciphertext byencrypting the commitment random number based on a homomorphicencryption public key of a remitter account and the transaction amountusing a homomorphic encryption algorithm.

In the implementations, the homomorphic encryption algorithm caninclude, for example, the Okamoto-Uchiyama algorithm and theBoneh-Goh-Nissim algorithm. Taking the Okamoto-Uchiyama algorithm as anexample, the first commitment random number ciphertext can be calculatedbased on equation OU_A(r)=u1^(r)v1^(t), where OU_A(r) is the firstcommitment random number ciphertext; r is the commitment random number;each of u1 and v1 is a portion of the homomorphic cryptographic publickey of the remitter account, respectively; t is the transaction amount.In the implementations, the commitment random number can be used as anencrypted plaintext, and the transaction amount can be used as a randomnumber for homomorphic encryption, thereby enabling encryption of thecommitment random number.

Step S14: Obtain a second commitment random number ciphertext byencrypting the commitment random number based on a homomorphicencryption public key of a remittee account and the transaction amountusing the homomorphic encryption algorithm.

In the implementations, the homomorphic encryption algorithm caninclude, for example, the Okamoto-Uchiyama algorithm and theBoneh-Goh-Nissim algorithm. Taking the Okamoto-Uchiyama algorithm as anexample, the second commitment random number ciphertext can becalculated based on equation OU_B(r)u2^(r)v2^(t), where OU_B(r) is thesecond commitment random number ciphertext; r is the commitment randomnumber; each of u2 and v2 is a portion of the homomorphic cryptographicpublic key of the remittee account, respectively; t is the transactionamount. In the implementations, the commitment random number can be usedas an encrypted plaintext, and the transaction amount can be used as arandom number for homomorphic encryption, thereby enabling encryption ofthe commitment random number.

Step S16: Submit transaction data to the blockchain.

In the implementations, the transaction data can include the transactionamount commitment, the first commitment random number ciphertext, andthe second commitment random number ciphertext. The remitter device cansubmit the transaction data to the blockchain, for the transactionamount commitment and the first commitment random number ciphertext tobe recorded into the remitter account, and the transaction amountcommitment and the second commitment random number ciphertext to berecorded into the remittee account.

Specifically, after the transaction data is submitted to the blockchain,a consensus blockchain node in the blockchain network can update theremitter balance commitment based on the transaction amount commitment;update the remitter random number ciphertext based on the firstcommitment random number ciphertext; update the remittee balancecommitment based on the transaction amount commitment; and update theremittee random number ciphertext based on the second commitment randomnumber ciphertext. The consensus blockchain node can be a blockchainnode determined based on a consensus mechanism of the blockchainnetwork. As such, the transaction data can be recorded into a blockchainledger maintained by each blockchain node in the blockchain network, soas to avoid tampering.

An updated remitter balance commitment can be a quotient of the remitterbalance commitment and the transaction amount commitment. Because theremitter balance commitment and the transaction amount commitment areimplemented by using a homomorphic commitment mechanism, the transactionamount can be deducted from the remitter balance and the commitmentrandom number can be deducted from the remitter random number. Forexample, the remitter balance commitment can bePC(r_A,s_A)=g^(r_A)h^(s_A); the transaction amount commitment can bePC(r,t)=g^(r)h^(t); the updated remitter balance commitment can bePC(r_A−r,s_A−t)=PC(r_A,s_A)/PC(r,t)=g^((r_A−r))h^((s_A−t)).

An updated remitter random number ciphertext can be a quotient of theremitter random number ciphertext and the first commitment random numberciphertext. Because the remitter random number ciphertext and the firstcommitment random number ciphertext are calculated by using thehomomorphic encryption algorithm, the transaction amount can be deductedfrom the remitter balance, and the commitment random number can bededucted from the remitter random number. For example, the remitterrandom number ciphertext can be OU_A(r_A)=u1^(r_A)v1^(s_A); the firstcommitment random number ciphertext can be OU_A(r)=u1^(r)v1^(t); theupdated remitter random number ciphertext can beOU_A(r_A−r)=OU_A(r_A)/OU_A(r)=u1^(r_A−r)v1^(s_A−t).

An updated remittee balance commitment can be a product of the remitteebalance commitment and the transaction amount commitment. Because theremittee balance commitment and the transaction amount commitment areimplemented by using the homomorphic commitment mechanism, thetransaction amount can be added to the remittee balance and thecommitment random number can be added to the remittee random number. Forexample, the remittee balance commitment can bePC(r_B,s_B)=g^(r_B)h^(s_B); the transaction amount commitment can bePC(r,t)=g^(r)h^(t); the updated remittee balance commitment can bePC(r_B+r,s_B+t)=PC(r_B,s_B)PC(r,t)=g^((r_B+r))h^((s_B+t)). r_B is theremittee random number; s_B is the remittee balance; g and h arepre-determined parameters, respectively.

An updated remittee random number ciphertext can be a product of theremittee random number ciphertext and the second commitment randomnumber ciphertext. Because the remittee random number ciphertext and thesecond commitment random number ciphertext are calculated by using thehomomorphic encryption algorithm, the transaction amount can be added tothe remittee balance, and the commitment random number can be added tothe remittee random number. For example, the remittee random numberciphertext can be OU_B(r_B)=u2^(r_B)v2^(s_B); the second commitmentrandom number ciphertext can be OU_B(r)=u2^(r)v2^(t); the updatedremittee random number ciphertext can beOU_B(r_B+r)=OU_B(r_B)OU_B(r)=u2^(r_B+r)v2^(s_B+t).

In an implementation, the remitter device can further generate a firstzero-knowledge proof based on a zero-knowledge proof technique; and addthe first zero-knowledge proof to the transaction data for the consensusblockchain node to verify that the transaction amount is not less than0. The zero-knowledge proof technique can be implemented, for example,based on the zero-knowledge succinct non-interactive argument ofknowledge “zkSNARK” scheme. Further, the zero-knowledge proof techniquecan include a range proof technique. The remitter device can generate afirst range proof based on the range proof technique; and add the firstrange proof to the transaction data for the consensus blockchain node toverify that the transaction amount is not less than 0. The range prooftechnique can be implemented, for example, based on the Bulletproofsscheme or the Borromean ring signature scheme.

In an implementation, the remitter device can further generate a secondzero-knowledge proof based on the zero-knowledge proof technique; andadd the second zero-knowledge proof to the transaction data for theconsensus blockchain node to verify that the transaction amount is notgreater than the remitter balance. Further, the zero-knowledge prooftechnique can include the range proof technique. The remitter device cangenerate a second range proof based on the range proof technique; andadd the second range proof to the transaction data for the consensusblockchain node to verify that the transaction amount is not greaterthan the remitter balance.

In an implementation, the remitter device can further generate a thirdzero-knowledge proof based on the zero-knowledge proof technique; andadd the third zero-knowledge proof to the transaction data for theconsensus blockchain node to verify that the commitment random numberfor calculating the transaction amount commitment, the commitment randomnumber for calculating the first commitment random number ciphertext,and the commitment random number for calculating the second commitmentrandom number ciphertext are consistent with one another, and verifythat the transaction amount for calculating the transaction amountcommitment, the transaction amount for calculating the first commitmentrandom number ciphertext, and the transaction amount for calculating thesecond commitment random number ciphertext are consistent with oneanother.

For example, the third zero-knowledge proof can be (C, D, E, a, b).C=g^(r)*h^(t)*; D=u1^(r)*v1^(t)*; E=u2^(r)*v2^(t)*; x=Hash(C,D,E);a=r*+xr; b=t*+xt. r* and t* are random numbers generated by the remitterdevice and respectively correspond to the commitment random number r andthe transaction amount t; Hash represents a hash operation.

When verifying that all g^(a)h^(b)==CT^(x), u1^(a)v1^(b)==DM^(x), andu2^(a)v2^(b)==EN^(x) are valid, the consensus blockchain node considersthat the commitment random number for calculating the transaction amountcommitment, the commitment random number for calculating the firstcommitment random number ciphertext, and the commitment random numberfor calculating the second commitment random number ciphertext areconsistent with one another, and considers that the transaction amountfor calculating the transaction amount commitment, the transactionamount for calculating the first commitment random number ciphertext,and the transaction amount for calculating the second commitment randomnumber ciphertext are consistent with one another. T is the transactionamount commitment PC(r,t); M is the first commitment random numberciphertext OU_A(r); N is the second commitment random number ciphertextOU_B(r).

In an implementation, the remitter device can calculate the firsttransaction amount commitment based on the first commitment randomnumber and a first transaction amount; and calculate the secondtransaction amount commitment based on the second commitment randomnumber and a second transaction amount. The first commitment randomnumber and the second commitment random number can be generated by theremitter device. The first transaction amount can be a transactionamount to be transferred out of the remitter account. The secondtransaction amount can be a transaction amount to be transferred to theremittee account. As such, the transaction amount to be transferred outof the remitter account and the transaction amount to be transferred tothe remittee account can be distinguished.

The remitter device can obtain the first commitment random numberciphertext by encrypting the first commitment random number based on thehomomorphic encryption public key of the remitter account and the firsttransaction amount using the homomorphic encryption algorithm; obtainthe second commitment random number ciphertext by encrypting the secondcommitment random number based on the homomorphic encryption public keyof the remittee account and the second transaction amount using thehomomorphic encryption algorithm; and submit the transaction data to theblockchain. The transaction data can include the first transactionamount commitment, the second transaction amount commitment, the firstcommitment random number ciphertext, and the second commitment randomnumber ciphertext, for the first transaction amount commitment and thefirst commitment random number ciphertext to be recorded into theremitter account, and the second transaction amount commitment and thesecond commitment random number ciphertext to be recorded into theremittee account.

Specifically, after the transaction data is submitted to the blockchain,the consensus blockchain node can update the remitter balance commitmentbased on the first transaction amount commitment; update the remitterrandom number ciphertext based on the first commitment random numberciphertext; update the remittee balance commitment based on the secondtransaction amount commitment; and update the remittee random numberciphertext based on the second commitment random number ciphertext.

An updated remitter balance commitment can be a quotient of the remitterbalance commitment and the first transaction amount commitment; anupdated remitter random number ciphertext can be a quotient of theremitter random number ciphertext and the first commitment random numberciphertext; an updated remittee balance commitment can be a product ofthe remittee balance commitment and the second transaction amountcommitment; and an updated remittee random number ciphertext can be aproduct of the remittee random number ciphertext and the secondcommitment random number ciphertext.

Further, the remitter device can further generate a fourthzero-knowledge proof based on the zero-knowledge proof technique; andadd the fourth zero-knowledge proof to the transaction data for theconsensus blockchain node to verify that the first transaction amountfor calculating the first transaction amount commitment and the secondtransaction amount for calculating the second transaction amountcommitment are consistent with one another, so as to prevent thetransaction amount transferred out of the remitter account from beinginconsistent with the transaction amount transferred to the remitteeaccount.

In an implementation, the remitter device can further obtain signaturedata by signing the transaction data using a signature private key ofthe remitter account; and add the signature data to the transaction datafor the consensus blockchain node to perform signature verification.

In the implementations, the transaction amount commitment, the firstcommitment random number ciphertext, and the second commitment randomnumber ciphertext can be obtained by using the commitment mechanism andthe homomorphic encryption mechanism. The transaction amount commitment,the first commitment random number ciphertext, and the second commitmentrandom number ciphertext can be submitted to the blockchain, for thetransaction amount commitment and the first commitment random numberciphertext to be recorded into the remitter account, and the transactionamount commitment and the second commitment random number ciphertext tobe recorded into the remittee account. On the one hand, privacyprotection can be realized for transaction information such as thetransaction amount by using the commitment mechanism and the homomorphicencryption mechanism. On the other hand, the transaction can be smoothlycompleted in the blockchain without the remittee device by submittingthe transaction amount commitment, the first commitment random numberciphertext, and the second commitment random number ciphertext to theblockchain. Therefore, the implementation can realize privacy protectionunder a non-interactive condition.

Further, the remitter account can register the remitter balancecommitment and the remitter random number ciphertext in the blockchain.The remittee account can register the remittee balance commitment andthe remittee random number ciphertext in the blockchain. On the onehand, privacy protection can be realized for both the account balanceand the transaction amount. On the other hand, by registering theremitter random number ciphertext and the remittee random numberciphertext on the blockchain, the burden caused by locally keeping theremitter random number and the remittee random number off the chain canbe avoided, and the risk of loss can be avoided.

Refer to FIG. 1, FIG. 2 and FIG. 3. For ease of understanding, anexample scenario of an implementation of the present specification isdescribed below.

In this implementation, assume that the remitter account can beAccount_A. The remitter account Account_A can have a signaturepublic-private key pair and an encryption public-private key pair. Theremitter account Account_A can also register a remitter balancecommitment PC(r_A,s_A)=g^(r_A)h^(s_A) and a remitter random numberciphertext OU_A(r_A)=u1^(r_A)v1^(s_A). r_A is the remitter randomnumber; s_A is the remitter balance; g and h are pre-determinedparameters; each of u1 and v1 is a portion of the homomorphic encryptionpublic key of the remitter account.

Assume that the remittee account can be Account_B. The remittee accountAccount_B can have a signature public-private key pair and an encryptionpublic-private key pair. The remittee account Account_B can alsoregister a remittee balance commitment PC(r_B, s_B)g^(r_B)h^(s_B) and aremittee random number ciphertext OU_B(r_B)=u2^(r_B)v2^(s_B). r_B is theremittee random number; s_B is the remittee balance; g and h arepre-determined parameters; each of u2 and v2 is a portion of thehomomorphic encryption public key of the remittee account.

In the implementations, the example transaction of the scenario canimplement the transfer of transaction amount t from the remitter accountAccount_A to the remittee account Account_B. Specifically, for example,the remitter device can generate the commitment random number r;calculate the transaction amount commitment PC(r,t)=g^(r)h^(t) based onthe commitment random number r and transaction amount t; obtain thefirst commitment random number ciphertext OU_A(r)=u1^(r)v1^(t) byencrypting the commitment random number r based on the homomorphicencryption public key of the remitter account and transaction amount tusing the homomorphic encryption algorithm; obtain the second commitmentrandom number ciphertext OU_B(r)=u2^(r)v2^(r) by encrypting thecommitment random number r based on the homomorphic encryption publickey of the remittee account and transaction amount t using thehomomorphic encryption algorithm.

In this implementation, the remitter device can generate a firstzero-knowledge proof RP1, a second zero-knowledge proof RP2, and a thirdzero-knowledge proof RP3. The first zero-knowledge proof RP1 can be usedto verify that t≥0. The second zero-knowledge proof RP2 can be used toverify that s_A−t≥0. The third zero-knowledge proof RP3 can be used toverify that the commitment random number r in PC(r,t)=g^(r)h^(t), thecommitment random number r in OU_A(r)=u1^(r)v1^(t), and the commitmentrandom number r in OU_B(r)=u2^(r)v2^(t) are consistent with one another,and verify that transaction amount t in PC(r,t)=, transaction amount tin OU_A(r)=u1^(r)v1^(t), and transaction amount tin OU_B(r)=u2^(r)v2^(t)are consistent with one another.

In this implementation, the remitter device can obtain signature dataSIG by signing [PC(r,t), OU_A(r), OU_B(r), RP1, RP2, RP3] using asignature private key of the remitter account; and submit transactiondata [PC (r,t), OU_A(r), OU_B(r), RP1, RP2, RP3, SIG] to the blockchain.

In this implementation, the blockchain network can determine a consensusblockchain node based on the consensus mechanism. By using theanti-double-spending or anti-replay mechanism of the relatedtechnologies, the consensus blockchain node can verify whether thetransaction has been executed. If the transaction has been executed, theconsensus blockchain node can reject the transaction.

If the transaction has not been executed, the consensus blockchain nodecan verify whether the signature data SIG in the transaction data iscorrect. If the signature data SIG is incorrect, the consensusblockchain node can reject the transaction.

If the signature data SIG is correct, the consensus blockchain node cancheck the first zero-knowledge proof RP1 in the transaction data toverify whether t≥0 is satisfied. If not satisfied, the consensusblockchain node can reject the transaction.

If satisfied, the consensus blockchain node can check the secondzero-knowledge proof RP2 in the transaction data to verify whethers_A−t≥0 is satisfied. If not satisfied, the consensus blockchain nodecan reject the transaction.

If satisfied, the consensus blockchain node can check the thirdzero-knowledge proof RP3 in the transaction data to verify whether thecommitment random number r in PC(r,t)=g^(r)h^(t), the commitment randomnumber r in OU_A(r)=u1^(r)v1^(t), and the commitment random number r inOU_B(r)=u2^(r)v2^(t) are consistent with one another, and verify whethertransaction amount t in PC(r,t)=g^(r)h^(t), transaction amount t inOU_A(r)=u1^(r)v1^(t), and transaction amount t in OU_B(r)=u2^(r)v2^(t)are consistent with one another. If not satisfied, the consensusblockchain node can reject the transaction.

If satisfied, the consensus blockchain node can update the remitterbalance commitment PC(r_A,s_A), the remitter random number ciphertextOU_A(r_A), the remittee balance commitment PC(r_B,s_B), and the remitteerandom number ciphertext OU_B(r_B). Specifically, the updated remitterbalance commitment can bePC(r_A−r,s_A−t)=PC(r_A,s_A)/PC(r,t)=g^((r_A−r))h^((s_A−t)); the updatedremitter random number ciphertext can beOU_A(r_A−r)=OU_A(r_A)/OU_A(r)=u1^(r_A−r)v1^(s_A−t); an updated remitteebalance commitment can bePC(r_B+r,s_B+t)=PC(r_B,s_B)PC(r,t)=g^((r_B+r))h^((s_B+t)); an updatedremittee random number ciphertext can beOU_B(r_B+r)=OU_B(r_B)OU_B(r)=u2^(r_B+r)v2^(s_B+t).

Referring to FIG. 4, an implementation of the present specificationfurther provides a blockchain-based transaction apparatus. Thetransaction apparatus can include the following units: a calculationunit 20, configured to calculate a transaction amount commitment basedon a commitment random number and a transaction amount; a firstencryption unit 22, configured to obtain a first commitment randomnumber ciphertext by encrypting the commitment random number based on ahomomorphic encryption public key of a remitter account and thetransaction amount using a homomorphic encryption algorithm; a secondencryption unit 24, configured to obtain a second commitment randomnumber ciphertext by encrypting the commitment random number based on ahomomorphic encryption public key of a remittee account and thetransaction amount using the homomorphic encryption algorithm; and asubmission unit 26, configured to submit transaction data to theblockchain, the transaction data including the transaction amountcommitment, the first commitment random number ciphertext, and thesecond commitment random number ciphertext, for the transaction amountcommitment and the first commitment random number ciphertext to berecorded into the remitter account, and the transaction amountcommitment and the second commitment random number ciphertext to berecorded into the remittee account.

Referring to FIG. 5, an implementation of the present specificationfurther provides a remitter device. The remitter device can include amemory and a processor.

In this implementation, the memory can be implemented in any suitableway. For example, the memory can be a read-only memory, a mechanicalhard disk, a solid-state drive, a USB flash drive, etc. The memory canbe configured to store computer instructions.

In this implementation, the processor can be implemented in any suitableway. For example, the processor can be a microprocessor, a processor, ora computer readable medium storing computer readable program code (suchas software or firmware) that can be executed by the microprocessor orthe processor, a logic gate, a switch, an application-specificintegrated circuit (ASIC), a programmable logic controller, or abuilt-in microcontroller. The processor can execute the computerinstructions to perform the steps of: calculating a transaction amountcommitment based on a commitment random number and a transaction amount;obtaining a first commitment random number ciphertext by encrypting thecommitment random number based on a homomorphic encryption public key ofa remitter account and the transaction amount using a homomorphicencryption algorithm; obtaining a second commitment random numberciphertext by encrypting the commitment random number based on ahomomorphic encryption public key of a remittee account and thetransaction amount using the homomorphic encryption algorithm; andsubmitting transaction data to the blockchain, the transaction dataincluding the transaction amount commitment, the first commitment randomnumber ciphertext, and the second commitment random number ciphertext,for the transaction amount commitment and the first commitment randomnumber ciphertext to be recorded into the remitter account, and thetransaction amount commitment and the second commitment random numberciphertext to be recorded into the remittee account.

The implementations in the present specification are described in aprogressive method. For the same or similar parts in theimplementations, references can be made to each other. Eachimplementation focuses on a difference from other implementations.Especially, an apparatus implementation and a device implementation arebasically similar to a method implementation, and therefore aredescribed briefly. For related parts, refer to descriptions in themethod implementation.

After reading the present specification, a person skilled in the art canthink of any combination between some or all of the implementationsenumerated in the present specification without creative efforts. Thesecombinations are also within the scope disclosed and protected by thepresent specification.

In the 1990s, whether technology improvement is hardware improvement(for example, improvement of a circuit structure, such as a diode, atransistor, or a switch) or software improvement (improvement of amethod procedure) can be clearly distinguished. However, as technologiesdevelop, the current improvement for many method procedures can beconsidered as a direct improvement of a hardware circuit structure. Adesigner usually programs an improved method procedure to a hardwarecircuit, to obtain a corresponding hardware circuit structure.Therefore, a method procedure can be improved by using a hardware entitymodule. For example, a programmable logic device (PLD) (for example, afield programmable gate array (FPGA)) is such an integrated circuit, anda logical function of the programmable logic device is determined by auser through device programming. A designer performs programming to“integrate” a digital system to a single PLD, without requiring a chipmanufacturer to design and manufacture a dedicated integrated circuitchip 2. In addition, at present, instead of manually manufacturing anintegrated chip, this type of programming is mostly implemented by using“logic compiler” software. The programming is similar to a softwarecompiler used to develop and write a program. Original code needs to bewritten in a particular programming language for compilation. Thelanguage is referred to as a hardware description language (HDL). Thereare many HDLs, such as the Advanced Boolean Expression Language (ABEL),the Altera Hardware Description Language (AHDL), Confluence, the CornellUniversity Programming Language (CUPL), HDCal, the Java HardwareDescription Language (JHDL), Lava, Lola, MyHDL, PALASM, and the RubyHardware Description Language (RHDL). The very-high-speed integratedcircuit hardware description language (VHDL) and Verilog2 are mostcommonly used. A person skilled in the art should also understand that ahardware circuit that implements a logical method procedure can bereadily obtained once the method procedure is logically programmed byusing the several described hardware description languages and isprogrammed into an integrated circuit.

The system, apparatus, module, or unit illustrated in theimplementations can be implemented by using a computer chip or anentity, or can be implemented by using a product having a certainfunction. A typical implementation device is a computer. A specific formof the computer can be a personal computer, a laptop computer, acellular phone, a camera phone, an intelligent phone, a personal digitalassistant, a media player, a navigation device, an email transceiverdevice, a game console, a tablet computer, a wearable device, or anycombination thereof.

It can be understood from the descriptions of the implementations that aperson skilled in the art can clearly understand that the presentspecification can be implemented by using software and a necessarygeneral hardware platform. Based on such an understanding, the technicalsolutions in the present specification essentially or the partcontributing to the existing technology can be implemented in a form ofa software product. The computer software product can be stored in astorage medium, such as a ROM/RAM, a magnetic disk, or an optical disc,and includes several instructions for instructing a computer device(which can be a personal computer, a server, a network device, etc.) toexecute the method described in the implementations of the presentspecification or in some parts of the implementations of the presentspecification.

To provide further context for embodiments of this specification, and asintroduced herein, distributed ledger systems (DLSs) (which can also bereferred to as consensus networks, made up of peer-to-peer nodes), andblockchain networks, enable participating entities to securely, andimmutably, conduct transactions and store data. Although the termblockchain is generally associated with particular networks, and/or usecases, blockchain is used herein to generally refer to a DLS withoutreference to any particular use case.

A blockchain is a data structure that stores transactions in a way thatthe transactions are immutable. Thus, the recording of transactions on ablockchain is reliable and trustworthy. A blockchain includes one ormore blocks. Each block in the chain is linked to a previous blockimmediately before it in the chain by including a cryptographic hash ofthe previous block. Each block also includes a timestamp, its owncryptographic hash, and one or more transactions. Within a block, thetransactions, which have already been verified by the nodes of theblockchain network, are hashed and encoded into a Merkle tree. TheMerkle tree is a data structure in which each leaf node includes a hashon a corresponding transaction, and each non-leaf node includes a hashon the concatenation of the hashes in its children. With this processcontinuing up the tree to the root of the entire tree, the root nodeincludes a hash that is representative of all data in the tree. A hashpurporting to be of a transaction stored in the tree can be quicklyverified by determining whether it is consistent with the structure ofthe tree.

Where a blockchain is a decentralized or at least partiallydecentralized data structure for storing transactions, a blockchainnetwork is a network of computing nodes that manage, update, andmaintain one or more blockchains by broadcasting, verifying andvalidating transactions, etc. As introduced above, a blockchain networkcan be provided as a public blockchain network, a private blockchainnetwork, or a consortium blockchain network. Embodiments of thisspecification are described in further detail herein with reference to aconsortium blockchain network. However, embodiments of thisspecification can be realized in any appropriate type of blockchainnetwork.

In general, a consortium blockchain network is private among theparticipating entities. In a consortium blockchain network, theconsensus process is controlled by an authorized set of nodes, referredto as consensus nodes, one or more of which are operated by a respectiveentity (a financial institution, insurance company, etc.). For example,a consortium of ten (10) entities (financial institutions, insurancecompanies, etc.) can operate a consortium blockchain network, each ofwhich operates at least one node in the consortium blockchain network.

In some examples, within a consortium blockchain network, a globalblockchain is provided as a blockchain that is replicated across allnodes. That is, all consensus nodes are typically in perfect stateconsensus with respect to the global blockchain. To achieve consensus(agreement to the addition of a block to a blockchain), a consensusprotocol or algorithm is implemented within the consortium blockchainnetwork. For example, the consortium blockchain network can implement apractical Byzantine fault tolerance (PBFT) consensus, described infurther detail below.

FIG. 6 is a diagram illustrating an example of an environment 1100 thatcan be used to execute embodiments of this specification. In someexamples, the environment 1100 enables entities to participate in aconsortium blockchain network 1102. The environment 1100 includes aplurality of computing devices 1106, 1108, and a network 1110. In someexamples, the network 1110 includes a local area network (LAN), widearea network (WAN), the Internet, or a combination thereof, and connectsweb sites, user devices (computing devices), and back-end systems. Insome examples, the network 1110 can be accessed over a wired and/or awireless communications link. In some examples, the network 1110 enablescommunication with, and within the consortium blockchain network 1102.In general the network 1110 represents one or more communicationnetworks. In some cases, the network 1110 includes network hardware suchas switches, routers, repeaters, electrical cables and optical fibers,light emitters and receivers, radio transmitters and receivers, and thelike. In some cases, the computing devices 1106, 1108 can be nodes of acloud computing system (not shown), or each computing device 1106, 1108can be a separate cloud computing system including a number of computersinterconnected by a network and functioning as a distributed processingsystem.

In the depicted example, the computing systems 1106, 1108 can eachinclude any appropriate computing system that enables participation as anode in the consortium blockchain network 1102. Examples of computingdevices include, without limitation, a server, a desktop computer, alaptop computer, a tablet computing device, and a smartphone. In someexamples, the computing systems 1106, 1108 host one or morecomputer-implemented services for interacting with the consortiumblockchain network 1102. For example, the computing system 1106 can hostcomputer-implemented services of a first entity (user A), such as atransaction management system that the first entity uses to manage itstransactions with one or more other entities (other users). Thecomputing system 1108 can host computer-implemented services of a secondentity (user B), such as a transaction management system that the secondentity uses to manage its transactions with one or more other entities(other users). In the example of FIG. 6, the consortium blockchainnetwork 1102 is represented as a peer-to-peer network of nodes, and thecomputing systems 1106, 1108 provide nodes of the first entity andsecond entity, respectively, which participate in the consortiumblockchain network 1102.

FIG. 7 depicts an example architecture 1200 in accordance withembodiments of this specification. The example architecture 1200includes participant systems 1202, 1204, 1206 that correspond toParticipant A, Participant B, and Participant C, respectively. Eachparticipant (user, enterprise, etc.) participates in a blockchainnetwork 1212 provided as a peer-to-peer network including a plurality ofnodes 1214, at least some of which immutably record information in ablockchain 1216. Although a single blockchain 1216 is schematicallydepicted within the blockchain network 1212, multiple copies of theblockchain 1216 are provided, and are maintained across the blockchainnetwork 1212, as described in further detail herein.

In the depicted example, each participant system 1202, 1204, 1206 isprovided by, or on behalf of, Participant A, Participant B, andParticipant C, respectively, and functions as a respective node 1214within the blockchain network 1212. As used herein, a node generallyrefers to an individual system (computer, server, etc.) that isconnected to the blockchain network 1212, and enables a respectiveparticipant to participate in the blockchain network. In the example ofFIG. 7, a participant corresponds to each node 1214. It is contemplated,however, that a participant can operate multiple nodes 1214 within theblockchain network 1212, and/or multiple participants can share a node1214. In some examples, the participant systems 1202, 1204, 1206communicate with, or through, the blockchain network 1212 using aprotocol (hypertext transfer protocol secure (HTTPS)), and/or usingremote procedure calls (RPCs).

Nodes 1214 can have varying degrees of participation within theblockchain network 1212. For example, some nodes 1214 can participate inthe consensus process (as miner nodes that add blocks to the blockchain1216), while other nodes 1214 do not participate in the consensusprocess. As another example, some nodes 1214 store a complete copy ofthe blockchain 1216, while other nodes 1214 only store copies ofportions of the blockchain 1216. For example, data access privileges canlimit the blockchain data that a respective participant stores withinits respective system. In the example of FIG. 2, the participant systems1202, 1204 store respective, complete copies 1216′, 1216″, 1216′″ of theblockchain 1216. In the descriptions herein, nodes 1214 of theblockchain network 1212 are also referred to as “participant user” fordescriptive purposes. In some embodiments, some or all of theparticipant users 1214 participate in the consensus process and arereferred to as “consensus nodes”. The consensus nodes for the blockchain1216 may also include other nodes not selected from the participantusers 1214. In some other embodiments, consensus nodes for adding blocksto the blockchain 1216 do not overlap with the participant users 1214that propose blocks to be added to the blockchain 1216.

A blockchain, such as the blockchain 1216 of FIG. 7, is made up of achain of blocks, each block storing data. Examples of data includetransaction data representative of a transaction between two or moreparticipants. While transactions are used herein by way of non-limitingexample, any appropriate data can be stored in a blockchain (documents,images, video, audio, etc.). Examples of a transaction can include,without limitation, exchanges of something of value (assets, products,services, currency, etc.) or occurrence of some events or activities.The transaction data is immutably stored within the blockchain. That is,an undetectable change cannot be made to the transaction data.

Before being stored in a block, the transaction data is hashed. Hashingis a process of transforming the transaction data, typically provided asstring data, into a fixed-length hash value, typically provided asstring data. It is not possible to un-hash the hash value to obtain thetransaction data. Hashing ensures that even a slight change in thetransaction data results in a completely different hash value. Further,and as noted above, the hash value is of a fixed length. That is, nomatter the size of the transaction data the length of the hash value isfixed. Hashing includes processing the transaction data through a hashfunction to generate the hash value. An example of a hash functionincludes, without limitation, the secure hash algorithm (SHA)-256, whichoutputs 256-bit hash values.

Transaction data of multiple transactions are hashed and stored in ablock. For example, hash values of two transactions are provided, andare themselves hashed to provide another hash. This process is repeateduntil, for all transactions to be stored in a block, a single hash valueis provided. This hash value is referred to as a Merkle root hash, andis stored in a header of the block. A change in any of the transactionswill result in change in its hash value, and ultimately, a change in theMerkle root hash.

Blocks are added to the blockchain through a consensus protocol.Multiple nodes within the blockchain network participate in theconsensus protocol, and perform work to have a block added to theblockchain. Such nodes are referred to as consensus nodes. PBFT,introduced above, is used as a non-limiting example of a consensusprotocol. The consensus nodes execute the consensus protocol to addtransactions to the blockchain, and update the overall state of theblockchain network.

In further detail, for example, the consensus node generates a blockheader, hashes all of the transactions in the block, and combines thehash value in pairs to generate further hash values until a single hashvalue is provided for all transactions in the block (the Merkle roothash). This Merkle root hash is added to the block header. The consensusnode also determines the hash value of the most recent block in theblockchain (the last block added to the blockchain) and adds the hashvalue of the most recent block into the block header. The consensus nodealso adds a nonce value, and a timestamp to the block header. The blockheader is hashed, which becomes the hash value of the block.

In general, PBFT provides a practical Byzantine state machinereplication that tolerates Byzantine faults (malfunctioning nodes,malicious nodes, etc.). This is achieved in PBFT by assuming that faultswill occur (assuming the existence of independent node failures, and/ormanipulated messages sent by consensus nodes). In PBFT, the consensusnodes are provided in a sequence that includes a primary consensus nodeand backup consensus nodes. The primary consensus node is periodicallychanged. Transactions are added to the blockchain by all consensus nodeswithin the blockchain network reaching an agreement as to the worldstate of the blockchain network. In this process, messages aretransmitted between consensus nodes, and each consensus nodes provesthat a message is received from a specified peer node and verifies thatthe message was not modified during transmission.

In PBFT, the consensus protocol is provided in multiple phases with allconsensus nodes beginning in the same state. To begin, a client sends arequest to the primary consensus node to invoke a service operation(execute a transaction within the blockchain network). In response toreceiving the request, the primary consensus node multicasts the requestto the backup consensus nodes. The backup consensus nodes execute therequest, and each sends a reply to the client. The client waits until athreshold number of replies are received. In some examples, the clientwaits for f+1 replies to be received, where f is the maximum number offaulty consensus nodes that can be tolerated within the blockchainnetwork. The final result is that a sufficient number of consensus nodescome to an agreement on the order of the record that is to be added tothe blockchain, and the record is either accepted, or rejected.

A consensus algorithm refers to a specific mechanism or terms, based onwhich a transaction or a block is verified and validated to be addedinto a blockchain. To that extent, a consensus algorithm is viewed as aspecific implementation agreement adapted to follow rules of a consensusprotocol. Different consensus algorithms may be created for differentblockchain networks 1212 or different blockchains 1216, which all complywith a same consensus protocol.

In some blockchain networks, cryptography is implemented to maintainprivacy of transactions. For example, if two nodes want to keep atransaction private, such that other nodes in the blockchain networkcannot discern details of the transaction, the nodes can encrypt thetransaction data. An example of cryptography includes, withoutlimitation, symmetric encryption and asymmetric encryption. Symmetricencryption refers to an encryption process that uses a single key forboth encryption (generating ciphertext from plaintext), and decryption(generating plaintext from ciphertext). In symmetric encryption, thesame key is available to multiple nodes, so each node canencrypt/decrypt transaction data.

Asymmetric encryption uses keys pairs that each include a private key,and a public key, the private key being known only to a respective node,and the public key being known to any or all other nodes in theblockchain network. A node can use the public key of another node toencrypt data, and the encrypted data can be decrypted using other node'sprivate key. For example, and referring again to FIG. 7, Participant Acan use Participant B's public key to encrypt data, and send theencrypted data to Participant B. Participant B can use its private keyto decrypt the encrypted data (ciphertext) and extract the original data(plaintext). Messages encrypted with a node's public key can only bedecrypted using the node's private key.

Asymmetric encryption is used to provide digital signatures, whichenables participants in a transaction to confirm other participants inthe transaction, as well as the validity of the transaction. Forexample, a node can digitally sign a message, and another node canconfirm that the message was sent by the node based on the digitalsignature of Participant A. Digital signatures can also be used toensure that messages are not tampered with in transit. For example, andagain referencing FIG. 7, Participant A is to send a message toParticipant B. Participant A generates a hash of the message, and then,using its private key, encrypts the hash to provide a digital signatureas the encrypted hash. Participant A appends the digital signature tothe message, and sends the message with digital signature to ParticipantB. Participant B decrypts the digital signature using the public key ofParticipant A, and extracts the hash. Participant B hashes the messageand compares the hashes. If the hashes are same, Participant B canconfirm that the message was indeed from Participant A, and was nottampered with.

The present specification can be applied to many general-purpose ordedicated computer system environments or configurations, for example, apersonal computer, a server computer, a handheld device or a portabledevice, a tablet device, a multi-processor system, amicroprocessor-based system, a set-top box, a programmable consumptionelectronic device, a network PC, a minicomputer, a mainframe computer,and a distributed computing environment including any one of theprevious systems or devices.

The present specification can be described in the general context ofcomputer executable instructions executed by a computer, for example, aprogram module. Generally, the program module includes a routine, aprogram, an object, a component, a data structure, etc., executing aspecific task or implementing a specific abstract data type. The presentspecification can also be practiced in distributed computingenvironments. In the distributed computing environments, tasks areperformed by remote processing devices connected through acommunications network. In a distributed computing environment, theprogram module can be located in both local and remote computer storagemedia including storage devices.

Although the present specification is described by using theimplementations, a person of ordinary skill in the art knows that manyvariations of the present specification can be made without departingfrom the spirit of the present specification. It is expected that theappended claims include these variations without departing from thespirit of the present specification.

What is claimed is:
 1. A method, comprising: calculating a remitterbalance commitment based on a remitter random number and a remitterbalance of a remitter account; calculating a remitter random numberciphertext by encrypting the remitter random number based on theremitter balance by using a homomorphic encryption algorithm; andregistering the remitter balance commitment and the remitter randomnumber ciphertext with a blockchain.
 2. The method according to claim 1,comprising: calculating a remittee balance commitment based on aremittee random number and a remittee balance of a remittee account;calculating a remittee random number ciphertext by encrypting theremittee random number based on the remittee balance by using thehomomorphic encryption algorithm; and registering the remittee balancecommitment and the remittee random number ciphertext with theblockchain.
 3. The method according to claim 1, comprising: receiving atransaction commitment between the remitter account and a remitteeaccount, the transaction commitment including a transaction commitmentamount and a remitter commitment random number ciphertext; updating theremitter balance commitment based on the transaction commitment amount;and updating the remitter random number ciphertext based on the remittercommitment random number ciphertext.
 4. The method according to claim 3,wherein: the updating the remitter balance commitment includescalculating a quotient of the remitter balance commitment and thetransaction amount commitment; and the updating the remitter randomnumber ciphertext includes calculating a quotient of the remitter randomnumber ciphertext and the remitter commitment random number ciphertext;5. The method according to claim 3, wherein: the transaction commitmentincludes a remittee commitment random number ciphertext; and the methodfurther comprises: updating the remittee balance commitment based on thetransaction commitment amount; and updating a remittee random numberciphertext based on the remittee commitment random number ciphertext. 6.The method according to claim 5, wherein: the updating the remitteebalance commitment includes calculating a product of the remitteebalance commitment and the transaction amount commitment; and theupdating the remittee random number ciphertext includes calculating aproduct of the remittee random number ciphertext and the remitteecommitment random number ciphertext.
 7. The method according to claim 3,wherein the updating the remitter balance commitment based on thetransaction commitment amount is conducted by a consensus node of ablockchain network that maintains the blockchain.
 8. A computing devicecomprising a processor and a memory, the memory storing executableinstructions that are executable by the processor to enable theprocessor to implement acts including: calculating a remitter balancecommitment based on a remitter random number and a remitter balance of aremitter account; calculating a remitter random number ciphertext byencrypting the remitter random number based on the remitter balance byusing a homomorphic encryption algorithm; and registering the remitterbalance commitment and the remitter random number ciphertext with ablockchain.
 9. The computing device according to claim 8, wherein theacts include: calculating a remittee balance commitment based on aremittee random number and a remittee balance of a remittee account;calculating a remittee random number ciphertext by encrypting theremittee random number based on the remittee balance by using thehomomorphic encryption algorithm; and registering the remittee balancecommitment and the remittee random number ciphertext with theblockchain.
 10. The computing device according to claim 8, wherein theacts include: receiving a transaction commitment between the remitteraccount and a remittee account, the transaction commitment including atransaction commitment amount and a remitter commitment random numberciphertext; updating the remitter balance commitment based on thetransaction commitment amount; and updating the remitter random numberciphertext based on the remitter commitment random number ciphertext.11. The computing device according to claim 10, wherein: the updatingthe remitter balance commitment includes calculating a quotient of theremitter balance commitment and the transaction amount commitment; andthe updating the remitter random number ciphertext includes calculatinga quotient of the remitter random number ciphertext and the remittercommitment random number ciphertext;
 12. The computing device accordingto claim 10, wherein: the transaction commitment includes a remitteecommitment random number ciphertext; and the acts further include:updating the remittee balance commitment based on the transactioncommitment amount; and updating a remittee random number ciphertextbased on the remittee commitment random number ciphertext.
 13. Thecomputing device according to claim 12, wherein: the updating theremittee balance commitment includes calculating a product of theremittee balance commitment and the transaction amount commitment; andthe updating the remittee random number ciphertext includes calculatinga product of the remittee random number ciphertext and the remitteecommitment random number ciphertext.
 14. The computing device accordingto claim 10, wherein the computing device includes a consensus node of ablockchain network that maintains the blockchain.
 15. A non-transitorystorage medium having computer executable instructions stored thereon,the computer executable instructions, when executed by a processor,configuring the processor to implement acts comprising: calculating aremitter balance commitment based on a remitter random number and aremitter balance of a remitter account; calculating a remitter randomnumber ciphertext by encrypting the remitter random number based on theremitter balance by using a homomorphic encryption algorithm; andregistering the remitter balance commitment and the remitter randomnumber ciphertext with a blockchain.
 16. The storage medium according toclaim 15, wherein the acts include: calculating a remittee balancecommitment based on a remittee random number and a remittee balance of aremittee account; calculating a remittee random number ciphertext byencrypting the remittee random number based on the remittee balance byusing the homomorphic encryption algorithm; and registering the remitteebalance commitment and the remittee random number ciphertext with theblockchain.
 17. The storage medium according to claim 16, wherein theacts include: receiving a transaction commitment between the remitteraccount and a remittee account, the transaction commitment including atransaction commitment amount and a remitter commitment random numberciphertext; updating the remitter balance commitment based on thetransaction commitment amount; and updating the remitter random numberciphertext based on the remitter commitment random number ciphertext.18. The storage medium according to claim 17, wherein: the updating theremitter balance commitment includes calculating a quotient of theremitter balance commitment and the transaction amount commitment; andthe updating the remitter random number ciphertext includes calculatinga quotient of the remitter random number ciphertext and the remittercommitment random number ciphertext;
 19. The storage medium according toclaim 17, wherein: the transaction commitment includes a remitteecommitment random number ciphertext; and the acts further include:updating the remittee balance commitment based on the transactioncommitment amount; and updating a remittee random number ciphertextbased on the remittee commitment random number ciphertext.
 20. Thestorage medium according to claim 19, wherein: the updating the remitteebalance commitment includes calculating a product of the remitteebalance commitment and the transaction amount commitment; and theupdating the remittee random number ciphertext includes calculating aproduct of the remittee random number ciphertext and the remitteecommitment random number ciphertext.